CD Ware Multimedia 1998 February/CD WARE MULTIMEDIA (02-1998) CD++.iso/Encript/JSTEG/JSTEG.TXT

Text File | 1997-12-18 | 5.7 KB | 113 lines

This version of the Independent JPEG Group's JPEG Software (release 4)
has been modifed for 1-bit steganography in JFIF output files.


To compile the package, simply follows the steps given in the original
README file.

To inject a data file into a JPEG/JFIF image, simply add the option
"-steg filename" to the "cjpeg" command line.  If the data file is too
large for the image, "cjpeg" will inform you.  At this point, you can
compress the data file, increase the quality of the image (thereby
increasing image size), or try a different image.

Extraction of a data file works similarly.  The "-steg filename"
option to "djpeg" writes the steganographic data to the file, wiping
out its previous contents.  Usually, the decoded image sent to
standard output is redirected to "/dev/null".


Steganography is the science of hiding data in otherwise plain text or
images.  Here, we are hiding the data inside images stored in the JFIF
format of the JPEG standard.  It was believed that this type of
steganography was impossible, or at least infeasible, since the JPEG
standard uses lossy encoding to compress its data.  Any hidden data
would be overwhelmed by the noise.  The trick used by this
steganographic implementation is to recognize that JPEG encoding is
split into lossy and non-lossy stages.  The lossy stages use a
discrete cosine transform and a quantization step to compress the
image data; the non-lossy stage then uses Huffmann coding to further
compress the image data.  As such, we can insert the steganographic
data into the image data between those two steps and not risk
corruption.

This method has several benefits.  First, the JPEG/JFIF image format
has become the de-facto standard for transmission across USENET and
for storage on FTP sites.  Steganography using these formats would be
innocuous compared to that with most other formats.  Second,
steganographic data in JPEG images is harder to detect with the naked
eye than the same data in raw 8-bit or 24-bit images.  Just as the
aforementioned lossy raw->encoded conversion tends to wipe out
steganographic data, the reversed, encoded->raw conversion tends to do
the same thing.  The steganographic inaccuracies in the image are
wiped over.  In addition, the wide control available over image
quantization makes it very difficult to establish whether or not the
inaccuracies which do appear are caused by steganographic data or by
lower-quality quantization.

The JPEG encoding procedure divides an image into 8x8 blocks of pixels
in the YCbCr colorspace.  Then they are run through a discrete cosine
transform (DCT) and the resulting frequency coefficients are scaled to
remove the ones which a human viewer would not detect under normal
conditions.  If steganographic data is being loaded into the JPEG
image, the loading occurs after this step.  The lowest-order bits of
all non-zero frequency coefficients are replaced with successive bits
from the steganographic source file, and these modified coefficients
are sent to the Huffmann coder.  (This choice of encoding slots produces
good results, but there may be better ones.  For example, tests have
shown that the human eye is less sensitive to changes along the Cb and
Cr colorspace axes---we ought to be able to stick more data there.)

The steganographic encoding format (the format of data inserted into
the lowest-order bits of the image) is as follows:

  +-----+-----------     -----+--------------------------------
  |  A  |  B  B  B  . . .  B  |  C  C  C  C  C  C  C  C  C  C  . . .
  +-----+-----------     -----+--------------------------------

  "A" is five bits.  It expresses the length (in bits) of field B.
  Order is most-significant-bit first.

  "B" is some number of bits from zero to thirty-one.  It expresses
  the length (in bytes) of the injection file.  Order is again
  most-significant-bit first.  The range of values for "B" is 0 to
  one billion.

  "C" is the bits in the injection file.  No ordering is implicit on
  the bit stream.

This format is designed to make the steganographic data as innocuous
as possible.  (As one would expect, there is no magic cookie at the
front giving the format).  We are forced to have a length field at the
beginning of the data, since any sort of in-band EOF tag would be
infeasible.

Expressing the length field as a raw series of bits representing an
integer would be dangerous, however; for any sort of small
steganographic file, there would be a long string of zeroes in the
field---very easy to detect.  By stripping off the zeroes and creating
a secondary length field for our primary length field(!), we greatly
reduce the problem.  The five bits for the secondary length field is
small enough that runs of zeroes are not a problem, and it allows a
primary length field of up to thirty-one bits.

There is still a danger in that the sixth bit of the stream will
always be one; this is solved by tacking an extra zero onto the
beginning of the primary length field in half the cases.  This helps
randomize the output, although it reduces the representable data size
to one gigabyte.

The storage effectiveness for this steganographic technique is
reasonable, but not astounding.  Using the simple encoding criteria
described above, an N kilobyte data file fits when the resulting
JPEG/JFIF file is around C*N kilobytes, where C ranges from eight to
ten.  This is not much worse than raw 24-bit insertion, and the
possibility of tweaking with regards to colorspace could produce even
better results.  Compressing the steganographic file before injection
does not seem to greatly harm compression in the envelope image; the
data spreading that occurs during injection increases entropy enough
for Huffmann coding to work.

Derek Upham
[e-mail]